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ABSTRACT 


Information systems executives within Department of Defense (DoD) activities are 
being challenged to develop innovative ways in which information technology can 
contribute to the streamlining of DoD organizations. A key step in developing 
information systems that will meet the ftitur. needs of DoD organizations is to manage 
the data resource. This thesis examines the concepts, implementation strategies, and 
issues relating to data management and illustrates, using a case sbidy of the Department 
of the Army data management methodology, the critical success factors required to 
implement data management programs throughout the DoD. 
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I. DATA MANAGEMENT AND THE DEPARTMENT OF THE ARMY 


A. INTRODUCTION 

The challenges facing information system (IS) executives are numerous. Major 
challenges include: 

• Aligning IS with organizational goals and objectives 

® Developing strategies for using infonnation technology (IT) and data as strategic 

resources 

• Integrating IS throughout the organization 

• Using IT to improve business processes 

Department of Defense (DoD) IS executives are not immune to these challenges. 
In the wake of a declining budget and personnel reductions, there is increased pressure 
on DoD to develop innovative ways to use infonnation technology to streamline DoD 
organizations. One of the ways in which DoD expects to meet these challenges is 
through the Corporate Information Management (CIM) initiative. 

The focus of CIM is on enhancing the business process and improving the 
management of information. An important principle of the CIM initiative is to identify 
the effective practices in applying information technology within DoD agencies so that 
they can be borrowed and emulated throughout DoD. 
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B. PURPOSE OF THE RESEARCH 


The objective of this research is to conduct a case study to discuss the concepts and 
issues related to data management and its applicability to DoD. This particular study 
focuses on the Department of the Army’s (DOA) Data Management and Standards 
Program and how this policy can be successfully implemented throughout DoD as one 
of the key CIM information technology initiatives. The DOA was selected to participate 
in this study because of their aggressive approach in developing standard data structures, 
as well as an on-line data dictionary system to capture, standardize and manage data 
resources. 

This case study is a part of a larger study sponsored by the Director of Defense 
Information that focuses on important issues in the development and implementation of 
management information systems within DoD. Other topics in the case study series 
include: 

• Business re-engineering 

' Code reuse, and 

• Prototyping using fourth generation languages. 

C. RESEARCH METHODOLOGY 

To examine the concepts, implementation strategies, and issues related to data 
management and to illustrate the factors required to successfully implement a data 
management program, a literature review and case study approach were adopted. The 
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literature review was conducted to acquaint the reader with the challenges and issues 
facing IS executives and the critical role data management plays in an organization’s 
information resource management (IRM) policy. Data management concepts, 
methodologies and issues are discussed in detail to provide a foundation to analyze the 
Anny’s data management program. 

On-site interviews and follow-up phone conversations with DoD and Army IRM 
officials, as well as review of Anny regulations, were undertaken to present the Army’s 
data management program and their efforts thus far ui implementing that program. 
Finally, the Army’s data management program methodology and procedures were 
analyzed to provide some valuable lessons other organizations may wish to consider 
before implementing a data management program. 

D. RESEARCH RESULTS 

The results of our research on data management concepts and issues and the 
Army’s efforts in developing a comprehensive program, to manage the data resource are 
presented in the Appendix preceding this chapter. The following is a brief summary of 
our findings. 

The Army recognized nine years ago that data were a vital resource and began 
formulatiriP a nolir.v to idp.ntifv stan Har HiTP. and manacle that rpunnTV'f* an r»ait of 

overall IRM program. To identify the data that are of strategic importance to Army 
decision makers, the Army adopted a strategic data planning strategy. This strategy uses 
functional modeling to generate a hierarchical breakdown of the activities undertaken by 
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Army functional areas and data modeling to depict data entities and elements that are 
created and/or used by the functional area activities. 

Functional models are used by the Army to identify redundant activities or activities 
which may be improved by applying re-engineering techniques. The functional data 
models are integrated to form an Army-wide data model which serves as the basis for 
data definition, integration and sharing across the Army. Both functional and data 
models also serve as a basis in producing a framework for future information systems 
development. 

The data entities and elements identified during data modeling undergo a rigorous 
standardization procedure. This procedure involves documenting the elements’ attributes 
(definition, domain, and other administrative information), developing a name based on 
the Army’s naming convention, and validating the element to ensure it complies with 
Army data standards. 

The Army has currently identified 19 functional areas and has completed at least 
the strategic modeling phase on 16 of those areas. The modeling effon has identified 
over 650 data entities and more than 2450 data elements. The Army expects to complete 
mid-level management modeling by September 1994. Although implementation of the 
Army data management program is just beginning, the Army has begun to realize the 
benefits of standardized data in the development of new information systems and have 
also been able to identify areas in which they can improve their business processes. 
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The Army’s experience in developing and implementing their data management 


program provides some valuable lessons to other organizations within DoD: 


• Management commitment is necessary for the success of any data management 
progiam of the Army’s scope. Management must be willing to make a substantial 
investment, without realizing immediate payoffs. Success can only be achieved 
through strategic vision and sustained commitment. 

• Modeling the organization and its data should be undertaken before standardization. 
It is necessary to determine first what data are essential to the organization and 
who uses the data. 

• An effective data management program takes time and resources. A data 
management program can provide long term benefits, but requires an up-front 
contribution of personnel, time, and budgetary resources. 


Despite its size and complexity, the Army has demonstrated that an organization-wide 
data management philosophy is not only viable, but also necessary for the effective 
control of information resources. 
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I. Executive Summary 


Streamlining DoD through Information Technology 

Sweeping changes ai-e being felt throughout the Department of Defense (DoD). 
The end of the cold war has meant that the military services must redefine their missions 
and must be able to perform their new missions with fewer personnel and within the 
constraints of a seriously declining budget. One of the ways in which DoD can operate 
in this "leaner and meaner" environment is to leverage information technology to their 
benefit. 


DoD has embraced this philosophy through the Corporate Information 
Management (CIM) program. The focus of CIM is on enhancing the business process 
and improving the management of information. By understanding how DoD 
organizations operate — what processes they perform and what data they need to execute 
those processes — DoD managers will be able to streamline their business functions and 
develop information systems to meet the needs of the organization. 


The Department of the Army (DOA) recognized nine years ago that data were a 
vital resource and began fonnulating a policy to identify, standardize, and manage that 
resource. DOA began implementing their data management program in 1990. Although 


A A n m a m m • A tv ^ A w . 1^ a « ^ -I _... — 1*. j.1. _ 
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benefits of standardized data in the development of new information systems and have 
also been able to identify areas in which they can improve their business processes. 


Movement Towards Data Management in the DOA 

The Paperwork Reduction Act of 1 >80 mandated that executive agencies assign 
a senior information resource management (IRM) official and ensure that automatic data 
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processing equipment is acquired and used in a manner wliich improves services and 
program management, increases productivity, and reduces waste and the information 
processing burden for the fedeial government. Federal agencies have been encouraged 
to develop strategic, tactical, operational, and information system plans to determine their 
information resource needs. The Army complied with these directives through Army 
Regulation (AR) 25-1, the Army Information Resource Management Program, but soon 
realized that successful planning for information resources depended on being able to first 
identify and manage its data resource. 

The Army began formulating a data management policy in 1984 while conducting 
a feasibility study for an Army corporate database. The implementation strategy for the 
corporate database called for the development of common data structures which would 
be defined in an Army-wide data dictionary. Although the corporate database project 
was canceled in 1988, the Army continued work on their strategy for a centralized 
approach to managing data and on the data dictionary as a tool to assist in implementing 
that strategy. The result was the Array Data Management and Standards Program (AR 
25-9) and the Army Data Dictionary/Automated Dictionary Support System 
(ADD/ADSS). 

The crux of the Army’s data management program is to identify and to 
standardize data so that it can be shared across functional boundaries. ITie ADD/ADSS 
provides a mechanism to capture, standardize, and merge the information the Army needs 
to manage its data resources effectively. The ADD/ADSS was so successful that it was 
awarded a "golden nugget" by the Director of Defense Infonnation and is cuirently being 
modified for use DoD wide. 


Data Management Methodology in DOA 

Using strategic data planning, the Army has been able to identify Army-wide data 
requirements and use those requirements as a basis for developing information systems 
that will meet their needs in the future. The Army’s strategic data planning process is 
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an iterative approach that uses modeling to represent Army business functions and 
information requirements. These models are initially developed at a high level to identify 
major business functions and essential information. Specific details regarding each 
business function and the information that is created or used in tliat function are captured 
in subsequent modeling efforts. The Army uses these models to develop bluqjrints for 
future information systems predicated on stable data needs. 


Lessons Learned 

Tlie Army’s experience in developing and implementing their data management 

program provides valuable lessons to other organizations within DoD: 

Management commitment is necessary for the success of any data management 
program of this scope. 

® Tlie data manager must be in a position of authority for the program to succeed. 

• Effective communication between those who make policy and those who 
implement policy is a key ingredient to the success and effectiveness of that 
policy. 

• The data manager, data administrator, and the database administrator must have 
the technical tools available to implement the data management policy. 

• Modeling the organization and its data should be undertaken before standardizing 
data to determine what data is essential to the organization and who uses it. 

• End-users play a critical role in the success of the data management program. 
They are the resident experts on how the business operates and what data is 
required to perform the job. 

• An effective data management program takes time and resources. A sound data 
management program provides long term benefits, but requires an up-front 
contribution of personnel, time, and budgetarj' resources. 

• Data management and IKM is a continual process. Models and architectures must 
be updated as processes are re-engineered, new information systems are 
developed, or new technology is acquired if the organization is to gain long-term 
benefits. 








Purpose of Case Study 


The puipose of the case study which follows is to: 

Acquaint the reader with the challenges and issues facing information systems 
executives 

Discuss the basic concepts of data management and key steps in implementing a 
data management pn^gram 

Present the Army’s data management program and their efforts thus fai in 
implementing the program, and 

Highlight the key lessons learned by the Army in implementing their strategy. 
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n. Management Information Systems in the 90’s: 
Issues and Challenges 


As information processing becomes more and more prominent in organizations, 
it is vital that computer systems be designed and implemented in a short time, without 
excessive costs, and meet the needs of the organization and its end-users. This is bom 
out by a recent survey of information system (IS) executives which lists the 14 top 
management issues they face for 1992.* These issues, listed in Table 1, can be 
aggregated into four main categories: 

• Using information technology (IT) and data as a strategic resource 

• Creating an information architecture that reflects organizational goals and 
objectives 

• Integrating information systems 

• instituting Total Quality Management in IS 

Industry is not alone in trying to cope with the problems related to IS. A recent 
survey details major and specific issues of paramount importance to the Department of 
Defense (DoD).^ These issues, listed in Table 2, include: 

• Strategic use of IS and data 

• Integration of IS 

• Infon lation security and control 

• Aligning IS with the objectives of the entire command 


'Champy, 1992. 
*Gacel, 1991. 
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• Aligning IS and Corporate Goals 

• Re-engineering Business Processes through IT 

• Creating an information Architecture 

• Utilizing Data 

• Improving the IS Human Resource 

• Instituting Cross-Functional Information Systems 

• Improving Software Development Quality 

• Improving Leadership Skills in IS 

• Boosting Software Development Productivity 

• Developing an IS Strategic Plan 

• Cutting IS Costs 

• Instituting Total Quality Management in IS 

• Integrating Information Systems 

• Using IS for Competitive Breakthroughs 

• Managing Dispersed Systems 

Table 1. Top Management Issues of IS Executives for 1992 


• Funding for IS 

To bring focus to the above DoD issues, the Corporate Information Management (CIM)^ 
initiative has become a driving factor in decisions regarding the development and use of 
information systems by DoD executives. 


’For information regarding CIM see Brewin, 1991. 
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• Improving IS strategic planning 

• Integrating data processing, office automation, and telecommunications 

• Improving information security and control 

• Making effective use of data as an organizational resource 

• Aligning an IS activity with tlie objectives of the entire command 

• Improving the quality of software development 

• Facilitating and managing end user computing 

• Increasing understanding of the role and contribution of IS 

• Establishing a streamlined, more efficient procurement process 

• Determining IS funding levels 

Table 2. Top Ten Critical MIS Issues in DoD 


Despite the recognition of critical issues by executives, the deployment of 
information systems has been and continues to pose complex problems to organizations. 
Many Achilles heels have been identilled with respect to information systems 
development: 

• Backlogs of several years for new systems development 

• The cost of developing and maintaining systems 

• Inability of management to obtain the information needed from computers to 
make decisions 

• Redundant and often inconsistent data 

• Timeliness and accuracy of data 
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I 

■ In an attempt to deal with these pressing problems, concepts such as "re- 

^ engineering** and "information engineering** have been added to the portfolio of today’s 

I IS managers. 

I 

! A. Data as a Strategic Resource 

I Regardless of whether the playing field is DoD or the private sector, two major 

! themes stand out — executives need timely and accurate information to make strategic 

I 

' decisions regarding the organization and IS must cross functional boundaries to provide 

i access to that information. 

As a strategic resource, information systems required to support the organization’s 
mission need access to data that are increasingly distributed throughout the organization. 
For most organizations, data are hidden in applications and processed on many different 
platforms making it difficult to obtain the integrated information needed for strategic 

I 

j decisions. Therefore, it is cntical to adopt an Information Resource Management (IRM) 

policy that promotes an enterprise-wide view of data and uses data processing systems 

I 

i to put IS resources to work as strategic weapons. 

IRM has evolved over several decades as organizations have learned how to 
assimilate information technology. IRM can be viewed as the policy arm for strategic 
sy.stems, however, fiom a practical standpoint, IRM is still an elusive concept. We will 
define IRM as the process of directing or controlling the use of an information system 
comprised of any combination of hardware, software, procedures, documents or paiple 
that transforms data into a meaningful and useful form for satisfying organizational goals 
and objectives. Tt is important to realize that data themselves are a resouice, in fact, the 
basic element from which information is derived. 

IRM is a learning process which organizations must undergo to achieve maturity 
in their use of IT as a strategic resource. Ideally, an organization reaches maturity when 
their IT is fully integrated into the organization and when plans, policies, and control 
mechanisms reflect IRM concepts. 
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B, Evolution of IRM 


IS researchers have proposed a number of models that try to capture the evolution 
of information technology within an organization * These models provide a basis for 
information resource managers to ascertain where their organization lies with respect to 
computer technology and to development of realistic plans for IRM. 

Common themes which appear in these models are organizational structure and 
the management of change in a technological enviionment. These themes lead to the 
following observations concerning the evolution of IRM: 

• There is a correlation between organizational structure and the IRM strategy an 
organization should adopt for a given rate of technology diffusion. For 
mechanistic organizations such as the DoD a reasonable IRM plan should ensure 
a low rate of growth during the initial stages of technological learning and then 
adopt a higher rate of growth once they begin to integrate that technology 
throughout the organization. 

• There is an ongoing shift between centralization and decentralization of IT. This 
shift is caused by the degree of control (financial, developmental, and operational) 
the organization exerts over the difftision of technology and the rate of 
technological growth the organization desires. 

• The growth of IRM follows organizational learning about computing technology. 
Tlie organization moves through stages of technology assimilation’, each stage 
building on the stage before it as the organization strives for equilibrium in their 
IRM strategy for that technology, 

• Management activities within each stage should include policy setting, planning, 
support, and control for the IRM strategy and the current technology, as well as 
educating the organization, gaining upper management commitment, and ensuring 
end-user involvement. 

• As a new techriology is adopted, the organization begins the learning process 
again with the goal of incoiporating the new technology into the existing IRM 


^Conceptual frameworks such as the Stage Model developed by Richard Nolan, the Integrative 
Framework for End-User Computing (EUC) developed by Alavi et al., and Brown and Bostrom’s 
model of EUC Management Effectiveness are excellent examples. 

*Nolan identifies six stages of data processing growth as: Initiation, Contagion, Control, 
Integration, Data administration, and Maturity. 
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philosophy. Thus there is no final stage for IRM, only maturity for an IRM 
strategy with respect to a certain technology. For example, organizations that 
have achieved maturity in the use of relational databases should start adopting an 
IRM strategy for Object Oriented Database (OODB), using what they have 
learned from the growth of relational databases and the IRM policies already in 
place. 

IR managers must have the technical tools available (data dictionaries, data 
encyclopedias, and I-CASE environments) to incorporate the IRM strategy. 


C. Information Engineering Tools 


If IRM is the policy arm for strategic systems, then information engineering is 
the vehicle for implementing that policy. Information engineering is based on the 
assumption that a relatively stable group of data lies at the center of the organization’s 
information processing needs.* Tools u.sed in information engineering provide support 
for data and process planning, analysis, design and construction. It is this support for 
that make information engineering tools so powerful for modeling the strategic needs of 
the enterprise. 

The basic tool for information engineering is the data dictionary. The idea of a 
central repository to store the organization’s standard data definitions and data models 
evolved from Database Management Systems (DBMS). As more and more organizations 
began to treat data as a valuable resource, it became apparent that DBMS specific 
dictionaries could not support an overall systems development process with the 
organization’s data needs as its focus. 

Information engineering has led to the development of central repositories that not 
only store the organization’s data, but also are used in conjunction with design tools such 
as Computer-Aided Software Engineering (CASE). CASE tools are intended to be a 
powerful extension of the data dictionary in that they automate the software development 


“Goodhue et al., 1992. 
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lifecycle. Unfortunately, most CASE tools on the maricet today are not able to support 
the full software development lifecycle. 

Information engineering techniques require a central repository that incorporates 
the features of a dictionary and a CASE tool repository. This has led to the concept of 
an encyclopedia, which is an extended central repository that: 

• Supports any vendor’s software development tool. 

• Associates the metadata’ it contains with applications resident on many different 
platforms. 

• Automatically updates the organization’s data architectures and models during 
software development. 

• Enforces the organization’s data management policies relating to the 
identification, naming, and maintenance of strategic systems. 

Currently there is no tool available on the market that truly fits the definition of 
an encyclopedia. However, once such a tool is available it will serve as the reference 
point for the development and implementation of all information processes for the 
organization. 


’Metadata is defined as data about the structure of data stored in the data dictionary. It 
includes the data name, format, lomain as well as otlier characteri.'itics. 
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m. Data Management: 
Concepts, Methodology, and Issues 


The basic element of information is data. The management of data musi be the 
first step in developing an information systems architecture, making effective use of the 
data resource and improving IS strategic planning. Data management is an integral part 
of IRM, which involves locating, organizing, cataloging, storing, retrieving, and 
maintaining data fundamental to the orgaitization. This proce^ consists of building 
models that reflect business functions and their associated information requirements. 
These models are not static, but change as the organization changes. 

The purpose of this chapter is to provide the reader with basic concqjts and issues 
in data management. A reader familiar with these concepts and issues may wish to skip 
this chapter. 

A. Evolution Toward Data Management 

The task of data management is to identify and control information that has 
strategic importance within an organization. The need for data control and management 
can be evidenced by the way organizations have developed information systems. This 
section traces the evolution of data management cm file processing to corporate 
databases. 




1. File Processing Systems 

When a user or computer application requests data, the information system must 
know what data are stored, how they are organized, and how to access them.* File 
processing systems, shown in Figure 1, keqj separate files for each application and the 
file layout is part of the application program. 
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Figure 1. An Example of File Processing 


In file processing systems, corporate information is embedded within the 
application program’s source code. The only way to gain access to the information is 


*Narayan, 1988 
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to access the application. For example, if the Billet application in Figure 1 were a 
COBOL program, it would contain a file section within the Data Division specifying 
basic information about each data element in the Billet file, including the size, the 
relative position within the record and file, and the access methods. For the Personnel 
Assigrjnent application to make use of the information contained in the Billet file, it 
would have to know the data structure. Since this information is embedded w ithin the 
Billet application, the Personnel application would have to access the Billet application 
file section. 

To circumvent these problems, data are often duplicated in separate files. While 
this duplication may be efficient, the tradeoff is a loss of data integrity. Data has 
integrity only if it is consistent. Duplication leads to inconsistencies in the organization’s 
data resource because updates to the same data that reside in separate files are often 
overlooked. Other limitations of file processing systems include: 

• Data are separated and isolated making integration difficult 

• Application programs are dependent on file formats, therefore a change in file 
format requires a change to the application programs that access that file 

• It is difficult to repre.sent complex objects using file processing systems’ 

2. Functional Databases 

As organizations learn that information needs to be shared, they realize that data 
must be independent of the applications that process them. Database Management 
Systems (DBMS) provide organizations with the technology for storing and retrieving 
data in a central and shared location. The most common DBMS are hierarchical, 
network, and relational. A DBMS is a set of programs that are used to define, process, 
and administer the database and its applications. Typical components of the DBMS are 
shown in Figure 2. 


’Kroenke and Dolan, 1988. 
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Figure 2. Typical Components of a DBMS (adapted from Kroenke and Dolan) 


The decision as to what data are to be stored in the functional database is usually 
based on the data requirements of departments within the organization. Thus each 
department or functional area (e.g., personnel, finance, operations) develops and 
maintains its own database (See Figure 3). The functional area defines the structure of 


thp flip anH u famtlv fr4 r\tw»r»cc 


of the data, called subschemas. The subschema can be displayed to users in the construct 


of forms and reports so as to obtain meaningful information. 


To define the database structure using the Definition Tools subsystem, entities'® 
are defined in the functional work environment. Once the en Sties are identified, their 


'“An entity is any person, place, or thing that has meaning to a user. 












Figure 3. An Example of a Functional Database 


attributes (characteristics) are specified. ITie attributes arc further defined by specifying 
their domain". For example, entities in tlie personnel department may consist of 
service member, service record, and dependents. The service member entity would be 
further defined as shown in Figure 4. 

When all ihe eniilics are iuciiiified, an entity-reiationship diagram is created to 
depict the rclatioi ships between entities. The list of entities, their attributes and 
domains, as well as the entity-relationship diagrams comprise the database schema. 


“Domain definitions specify formats, lengths, and special restrictions on the values of each 
domain. 
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ENTTITES 


ENTITY 

ATTRIBUTES 


DOMAIN 

DEFINmON 


Service 


Member 



Service 

Record 


Qualifications 


Dependents 


NAME: 

RANK: 

BIRTH DATE: 
MOS: 


BIRTH DATE: 

Definition: Date of individual's birth as 
written on birth certificate. 

Numeric: 999999 

Mask .YYMMDD where 
YY indicates iast 2 digits of bitth year, 
MM indicates month and 
DD Indicates day of month. 


Figure 4. An Example of Entity, Attributes, and Domain Definitions 


The data dictionary subsystem is a tool that facilitates storage of the organization’s 
metadata and has the capability to relate that information in such a way that the organized 
metadata serves a useful purpose.’^ The data dictionary contains different types of 
information about data stored in the database. This information includes: 

• Entity names and descriptions 

• Data item names, descriptions, origin, format, and access rights 

• Relationships between data items, entities, and application programs 


‘^Narayan, 1988. 












With the database technology described above, organizations have been able to 
use computer systems to represent their business enviromnent, while minimizing the 
dependence between application programs and data. Within each functional area, 
infonnation systems are developed so that data car be shared and duplication of data is 
minimized. 

Unfortunately, many organizations that utilize database technology still do not use 
data as a global resource. Often, functional areas within the organization develop and 
maintain databases which follow different rules about how data are stored and accessed. 
Lack of an overall data management and standardization policy usually results in the 
organization’s data being represented by different structures and different names within 
each functional database. 


3. Corporate Databases 

The need to share data across functional boundaries has led to the development 
of a central repository which should enable an organization to: 

• Develop cross-functional applications independent of the data 

• Promote the sharing of coiporate-wide data tlmough the use of common data 
structures 

• Allow for access of data by heterogeneous databases 

A central repository subsumes the features of a data dictionary as weU as 
infonnation about where and h( v data are stored in the databases. Figure 5 depicts the 
relationship of the repository {> the organization’s data. 

Integrated information computer architectures, such as the Infonnation Resource 
Dictionary System (IRDS) federal standard, provide facilities for recording, storing and 
processing descriptions of an organizations’s data and processing resources.'^ The use 
of such a tool enables data to be distributed and accessed from a heterogeneous network 


’’Schwartz, 1991. 
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Corporate 

Database 



of systems. In particular the IRDS allows managers to: 

• Develop and maintain coiporate-wdde data models that defme entities, entity 
relationships, and process models, which will ensure the same entity deHnitions 
are being used throughout the corporation. 

• Provide a central repository of information, a portion of which can be 
downloaded by application development tools such as CASE for the development 
of specific applications. 

• Provide a means for using strict data-administration control procedures that ensure 
changes to the local data mod-'l required by a new application will be 
incoiixJrated back into the central data model. 

• Coordinate database access and database access standards which will ensure data 
security and inl-:grity. 
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B. Basic Principles of Data Management 


This section briefly discusses the basic concepts of data management. These 
concepts, depicted in Figure 6, form the foundation of a sound data management 
program. 
















1. Key Personnel in Data Management 

An environment of shared data requires a data administrator (DA) who has the 
overall responsibility for the organization’s data resources. The DA implements 
methodologies for the centralized management and control of data resources. DAs and 
their assistants are responsible for planning and defining the conceptual framework for 
the overall database environment. 'Die DA interacts with end-users to assess their data 
requirements in terms of the organization’s needs. Functions of the DA are listed in 
Table 3. 


Manage and Control Data Resources 

* Strategic data pleuuiing 

* Standardized data naming convention 


Plan and Define Organization’s Database Environment 

• Functional and data architectures 

'* Functional and data models 

« Design database structure 


Provide Assistance to Database Users 

• Training 

• Support 


Maintain Database Integrity and Availability 

• Crc-St© dstsbsisc policy snd plsnning procedures, docunient^tion, 
and standards 


Table 3. Functions of the Data Administrator 
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Database Design 

* Evaluate technical needs 

* Propose technical standards, design rules, and conventions 

Database Implementation 

* Database loading, testing, and validation 

* Implement data defmitions 

* Implement and maintain data dictionary/encyclopedia and other database 
support software 


Database Security and Integrity 

• Install and maintain tools to guard against unauthorized access and 
unauthorized update, copying, removal, or destruction of the database 

• Install and maintain tools to ensure the correctness and accuracy of data 

Database Performance Monitoring and Evaluation 

• Review, test and evaluate the performance of activity against physical data 
structures 

• Initiate system improvements 

• Assesses the impact of change 

• Recommend database redefinition, redesign, and restructuring when 
indicated 

• Implement restart, recovery, and bacbip procedures 


Table 4. Functions of the Database Administiator 
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I 

Where the DA requires skills in management, the database administrator (DBA) 

is the organization’s technical expert on database related activities and has the 
I ' 

j responsibility for the operation of the oig;anization’s databases. Functions of the DBA 

are listed in Table 4. 
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2, Strategic Data Planning 


Unlike the bottom-up approach of file processing and functional databases where 
data are identified because of the need for a particular application or business function, 
strategic data planning (SDP) is a top-down strategy for identifying and understanding 
data in the context of the overall business functions. This approach relies on modeling 
the organization, its processes and its data as a basis for identifying and implementing 
an integrated set of information systems. The underlying assumption is that it is 
impossible to identify and develop information systems that will meet the needs of the 
organization without first knowing what the business is, what it does, and what data it 
uses.*'^ 


3. Functional and Data Modeling 

To gain an understanding of the organization’s processes and data, SDP 
approaches rely heavily on modeling. Two types of models are used in SDP. Functional 
models depict the activities or processes an organization performs to accomplish its 
mission. Data models describe the entities, their attributes and interrelations that are 
necessary to support the business processes. Modeling is an iterative process with each 
session adding more detail until the model accurately reflects the pixrcesses and data 
associated with the business unit being modeled. 


4. Information Systems Architectures 


An architecture is a framework for specuyuig how conrponenis of a system fit 
together. An information systems architecture provides a framework within which future 
IS development, procurement, and implementation activities can occur. IS architecture 


'^Goodhue et al., 1988. 
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involves logical and physical elements.*^ Logical elements include the rules, 
procedures, and principles by which an organization operates. Physical elements of the 
IS architecture include applications, data/information, hardware/softwane processing 
platforms and communications. 

An applications architecture accommodates all activities within the organization, 
from operations to strategic planning. The data architecture is the glue that binds the 
other architectures together. It represents the information the organization must keep 
track of to perform its mission. The hardware/software architecture provides the 
processing power to run applications that will generate and distribute corporate data. The 
communications architecture connects the above three architectures so that information 
can be shared. 


5. Data Standardization 

The role of a standard is to ensure that people and systems can communicate with 
each other in a consistent fashion*’. Data standardization ensures not only people (end- 
users, systems developers) can communicate, but also applications operating on 
heterogeneous platforms. Additional benefits of data standardization include: 

• A means to control, share and manage data 

• Cost reduction of managing data by eliminating duplication 

Once the organization’s data model is completed, the entities and the data 
elements used to describe those entities should be standardized. The standardization 
process includes: 

• Providing precise definitions for data entities and elements 

• Selecting entity and element names based on the organization ’ s naming convention 

’’Kanter and Miserendino, 1987. 

**Kanter and Miserendino, 1987. 

*’Narayan, 1988. 
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• Identifying data element characteristics (context, fonnat, domain) 

• Identifying aliases 

• Assigning tesponsibilities for specifications, definition, changes, etc 

• Identifying how the data is obtained (what process creates the data) and where it 
is used (what processes access the data) 

6. Naming Conventions 

Naming conventions help to establish consistency of data throughout the 
organization. There are many naming conventions currently being used’®. No matter 
what naming convention is used, the element should be named by what it is, not how it 
is used. For example, a social security number is used as an account number for pay 
purposes and also as a number to uniquely identify an individual. Should the data 
element be named pay-account-number or individual-social-security-number? Naming 
the data element what it is (individual-social-security-number), promotes application 
independence and more accurately conveys its proper meaning, which will facilitate 
communication. 


7. The Data Dictionary and Encyclopedia 

The data dictionaiy and encyclopedia are indispensable tools for data management 
and the data admii strator. The data dictionary provides a means to document, organize 

oiiu Oil ui^^aiuicaviuii uuuiuiatiuii AVMmivC/5. nd a lui duuiuaAUijcauuu, ii 

enforces the integrity of .he organization’s data. 

Used in the system development process, the data dictionary ensures that data 
standards are communicated and incorporated ii to the file stnictures and programs that 


“IBM’s "OF" convention and guidance put out by the National Institute of Standards and 
Technology are t,”amples. 
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are being developed. Documenting information about systems, programs and data files, 
reduces costs of future enhancements and maintenance of the systems. 

Combined with a data dictionary, the encyclopedia provides the added benefit of 
storing the oigani^ation’s data models and architectuies and documenting their 
relationships with the organization’s standard elements. The encyclopedia gives the data 
administrator a tool to analyze how a change in the organization’s business process will 
effect its data resource. A summary of the advantages of data dictionaries and 
encyclopedia is listed in Table 5. 


Data Dictionary 

• Repository for standardized data 

• Documents the relationship between data and information systems 

• Provides control over organizational data 

• Ensures data integrity 

• Aid in system development 

Encyclopedia 

• Develop and store organizational models 

• Document the relationship between models and data 

• Analyze the effects of change on organizational functions and data 

• Aid in system development 


Table 5. Benefits of a Data Dictionary and Encyclopedia 







C. Data Management Methodology 

The literature contains a number of approaches to manage organizational data.^’ 
The selection of a particular methodology will depend on the goals and objectives the 
organization has established for its data management and IRM programs. No matter 
what methodology an organization selects, there are certain key steps required in a sound 
data management program. These key steps are depicted in Figure 7 and are briefly 
discussed below. 



D«v«jop 

Informitlon 

Systems 

Architecture 


Figure 7. Key Steps in Data Management 


’’Examples include James Martin’s Strategic Data Planning and iBM’s Business Systems 
Planning (BSP). 











1. Gain Management Commitment 

Management commitment to a data management program is absolutely crucial. 
This commitment has to be given over an extended period without expecting immediate 
payoffs. Management commitment should be exhibited through: 

• Dedication of resources: personnel and money 

• Involvement and support of the strategic data planning pixx^ss 

* Support of standards including the data modeling methodology and naming 
convention, as well as procedures for the control of changes to the program 

* Support of the data dictionary and encyclopedia as the only source of data 
definitions for the entire organization^ 

Selling management may not be an easy task; however the task can be made 
easier by conveying the fact that substantial time, labor, and money is spent duplicating 
efforts to create new files out of existing data and new applications that process the data. 

2. Select Modeling Te.ani Participants 

Selecting the right participants is critical to tl i quality of the data management 
process. The modeling team should consist of at least one individual who is trained in 
the modeling process (a facilitator) and a group of functional personnel (end-user:) who 
are experts in their particular area. The team m -y also include IS personnel as required, 
bu care should be taken to ensure that IS personnel do not dominate the process. 

3. Model the Organization 

This step involves identifying business functions and the processes and activities 
within those functions that the organization performs. The major functions identified are 
grouped together in what is normally called an enterprise model. Each function in the 


“Narayan, 1988. 












enterprise model will be analyzed by performing functional modeling. During functional 
modeling, the business function is further broken down into processes and activities (both 
manual and automated). 

The functional models will assist the organization in identifying redundant 
nrocesses and apphcation programs that may be eliminated, processes that are currently 
supported by existing information systems, and processes which may be candidates for 
information technology. 


4. MoJel the Orgaish ation’s Data 

With the functional model as a guide, entities used by the various processes and 
activities are identified and placed into a functional data model. The data model is 
further refmed by associating the entities with the processes or activities that use or 
create them and by identifying relationships between entities. The data entities are also 
defined by documenting their definitions and characteristics. As each functional area 
completes its data model, it is integrated with other functional data models to identify 
data that can and should be shared. 

The result of this integration is a corporate data model comprised of entities that 
are of strategic importance to the organization. As with the functional data models, 
entity relationships are documented as are the processes that use the entity. In addition, 
the functional area that will have responsibility for gathering and maintaining data on the 
individual entities is designated. 


5. Standardize the Data 

In order for data to be shared it must have a common structure. Standardizing 
entities involves naming the entity using the organization’s naming convention, providing 
a precise definition, identifying its characteristics (attributes), and developing access 
keys. In many cases, a functional area will not require access to the entire entity, but 
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rather a subset (called a view) of the entity’s characteristics. These characteristics, 
referred to as data elements, must also be included in the standardization process. 


6. Develop an Information Systems Architecture 

When the functional and data models are complete, the organization will have a 
detailed picture of its business processes, how tliose processes gather, distribute, and use 
information, and what information is important to organizational goals and objectives. 
The modeling effort provides the organization with the opportunity to redesign the 
business based on information needs and build systems that will support the oiganization 
dynamically.^* 

'fhe information systems architecture provides the organization with the 
framework for re-engineering the business. The IS architecture i^resents an 
organization’s current and future applications, hardware and software, and 
communication and data ne&ds. These architectures assist the oiganization in developing 
a set of plans for migrating to the future with respect to their information systems. 

D. Issues in Implementing Data Management 

Tlie previous sections diiscussed the basic concepts of data management and the 
key steps in implementing a data management methodology. However, putting these 
concepts into practice still poses considerable problems for organizations. 


1. Centralization versus Decentralization 

The past thtee decade.s has seen continual tension over how information resources 
will be controlled. Management desire to control information resources has always 


’*Finkelstein, 1991. 
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tended towards some degree of centralization, whereas the proliferation of end-user 
technology, the need to access information in a timely fashion, and the size of 
organizations has placed pressures on management to decentralize resources. There are 
advantages to both strategies. While centralization appears to provide better security, 
integrity, and control, decentralization favors innovation and facilitates end-user support. 

The issue is one of balance. Management must balance tlie needs of the 
organization with the needs of end-users. Where that balance lies will dq>end on the 
organization. Total Quality Management (TQM) and re-engineering advocates support 
"decentralized centralization". This philosophy treats dispersed resources as if they were 
centralized. The use of a centralized database created by a sound data management 
policy supports the need for data security, integrity and control. By applying 
technologies such as telecommunication networks and implementing standardized 
processing systems, the relevant portions of an organization’s database can be 
downloaded into a functional database to provide end-users with the flexibility and 
service they require.’^ 


2. Data Standardization 

Standardization invariably will result in conflicts over ownership of data. If end- 
users do not believe data is a corporate resource they win be unwilling to share that data 
with others. Information is power and the person who owns the information holds the 
power. Along the same lines, end-users arc reluctant to surrender ownership of data that 
they believe belongs to their functional area for fear that the data will no longer be 
reliable. In some cases, no functional area will claim responsibility for the data, even 
though many functional areas use it frequently. Standardization requires that some group 
take responsibility for the data element’s lifecycle. Infighting can occur over wliich 
functional area should have stewardship over a data item. 


^^Hammer, 1990. 
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Second, data element naming can also result in conflicts between end-users, 
especially when elements are shared by several liinctional areas. The idea that a data 
element will be called anything other than the name familiar to a particular user may also 
cause conflict with end-users. The data administrator must be prepared to address and 
handle these problems. 


3. Data Security 

Security of data and databases has always been a critical and complex issue, 
especially in DoD. Security for dictionaries and encyclopedias compounds this issue 
because the organization's metadata resides in one location. Unauthorized access to the 
encyclopedia and dictionary could result i i compromise or a loss of data. In addition, 
although data element structures and I'elationsliips between entities and applications may 
be unclassified by themselves, the aggregate of that information may very well become 
classified. By having access to the metadata, users (authorized or unauthorized) could 
glean classified information. Dictionaries/encyclopedias constitute a single point of 
vulnerability and thus should be addressed in the organization’s security plan. 


4. D: *^a Integration 

Data integration across heterogeneous platfonns can be achieved in three ways: 
interfaces, common access to data, and common control and access to data.^ In 
interface-level integration data is passed from one platform to another through an 
interface. If data is changing on both sides of the interface, maintaining consistency 
between platforms can be difficult. 

Integration through common access to data greatly increases the level of 
coordination between products. Since different systems are unaware of the existence of 
other systems that use the same data, there is no mechaniem in place to ensure that the 


’’Aranow, 1989. 




changes introduced by one system are consistent with changes introduced by other 
systems. To address the problem of multiple platforms sharing data, common control 
of data access is necessary. Controls must ensure that data being entered are consistent 
both with the metamodel and with data that already exists and that changes to the data 
are regulated and tracked. 


5. Data Synchronization 

Synchronization refers to the consistency, accuracy, reliability, and timeliness of 
replicated data in distributed enviromnents. With the sharing of data across distributed 
databases, users may be reluctant to make decisions from data over which they do not 
have control. Organizations will need to develop policies and procedures that ensure 
timely updates to data as well as synchronizing those updates when copies of the database 
are distributed. 
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rv. Evolution of Data Management within DOA 


The previous sections presented the issues and challenges faced by organizations 
in dealing witli information systems and theoretical concepts that may be applied to meet 
those challenges. The Army has addressed some of the problems of managing 
information systems by developing a comprehensive program to manage data. The next 
two sections will present the Army’s data management program and provide some 
valuable lessons other organizations may wish to consider before implementing a data 
management program of their own. 


A. DOA Information Technology 

Like any large organization, the Army maintains a considerable amount of data 
concerning its personnel, equipment, installations, and finances. The majority of the 
application software currently operational that processes data consists of "stovepipe"^^ 
systems. The Army is spending about $1.7 billion a year to maintain and operate its 
"sustaining base"^ automation. This includes 3,700 applications amounting to almost 
200 million lines of code, of which 96% of this code are unique to specific commands 
and installations.^* 


“Systems developed to meet one functional area without taking into account other functional 
areas which potentially use the same information. 

^*rhe Army defines Sustaining Base as: The area and information resources outside of the 
area of operations that have the responsibility to raise, organize, train, equip, and eventually, 
deploy and sustain Army forces in the accomplishment of their mission in operational theaters. 

“Rogers, 1991. 
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Figure 8. Army Key Monnation Management Commands 


Army information rcsouiue management budget for Fiscal Year 1992 is $2.4 
billion. IRM employees number approximately 17,000. Key Army Information 
Resource Management Program (AIRMP) commands are depicted in Figure 8. 

The Office of Director Mormation Systems for Command, Control, 
Communications and Computers (ODISC4) is the policy arm for the Army’s IRM and 
Data Management program. DISC4 is primarily responsible for: 

• Information Management 

• Plans and Policies 

• Mormation Architecture and Models 

• Mormation Requirements Development 
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• Functional Inforai^tion Requirements Integration 

• Information Systems Programmatic Integration 

• Information Mission Area Program and Resource Integration 

Subordinate to DISC4 is the Architecture Directorate and the Director of Amy 
Information. The Architecture Directorate Standardization Division is re^wnsible for 
the Army’s Data Management and Standards Program (AR 25-9), while the Director of 
Anny Information Policy division oversees the Army’s Information Resource 
Management Program (AR 25-1). 

The United States Anny Information Systems Command (USAISC) is the Army’s 
primary provider of information management staff assistance and information systems 
operational support and services in the Army Strategic Environment” and Sustaining 
Base Environment. This command is responsible for establishing and maintaining the 
technical interface between Army information systems witldn the Strategic and Sustaining 
Base environments, between environments and with those external to the Army. 
USAISC is also resp<jnsible for technical infonnation systems integration and are the 
Infonnation Mission Area (IMA)” systems engineers. 

USAISC was appointed the Army Data Administrator by DISC4 and is given 
operational responsibility. This responsibility is delegated to the Data Management 
Directorate (DMD) of the Information Systems Software Center (ISSC), Infonnation 
Systems Engineering Command (ISEC). As the Army Data Administrator, DMD is 
responsible for the An.iy wide implementation oversight of the Army Data Management 
and Standards Program (ADMSP), 


”Within infonnation mission area (IMA), the environment which links the Theater/Tactical 
and Sustaining Base Environments. 

“'fhe resource requirements and associated infonnation management activities employed in 
the development, use, integration, and management of infonnation. Information resources 
include doctrine, policy, data, equipment, and applications and related personnel, services, 
facilities, and organizations. 
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B. DOA IRM Policy 


Prior to 1984 management of Army infoimation resources rested with the 
principal user of the information. Under this structure, little centralized control existed. 
Rather, individual users defined their particular information requirements, developed 
software, procured necessary hardware and communications, and linked these elements 
together to form information systems, usually fulfilling narrowly defined needs.^ 

The Paperwork Reduction Act of 1980 enc^ouraged federal agencies to view 
information as a valuable organizational resource and to develop managerial approaches 
to improve its collection, storage and dissemination^”. In order to carry out the 
provisions of this act, the Army established The Army Information Resources 
Management Program (AR 25-1) in 1984. The 1988 version of AR 25-1 specifies the 
following objectives of the AIRMP: 

• Establish a concept of operation and management processes and structures for the 
management of infonnation and information resources which ensures integration, 
sharing, standardization, interfacing, interoperability, timeliness, and accuracy of 
infonnation provided to Anny decision infers in peace, transition to and from 
conflict, and conflict. 

• Ensure that appropriate, timely, and accurate information is identified and made 
available for satisfying user requirements in the execution of Anny and Army 
supported responsibilities. 

• Ensure that existing information resources arc identified, information 
requirements are validated, and a sy.stematic approach for satisfying these 
requirements is established and maintained. 

• Ensure that it is applied in the management of ail IMA disciplines in all 
environments under all conditions for the Total Army. 

To implement the AIRMP the Army developed the Army Information Architecture 
(AIA). The ALA is the framework for developing information systems to support the 
Anny’s present and future mission requirements. The AIA structure (Figure 9) consists 


^GAO/IMTEC-90-58 "Army Information Resource Management" 
^Head, 1990. 
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I 

I of three architectures: Information Architecture, Control Architecture, and Information 

I ■ 

I Systems Architecture. 

I The total AIA is a composite of infonnation architectures of major 

i organizations^' within the Army. Each organization is required to develop and maintain 

i an organizational information architecture. Organizational information architectures 

reflect the requirements of the organization as well as subordinate activities and are 
guided by the information architecture of the next higher echelon. 

“Major organizations include Headquarters Department of the Army agencies and their field 
operation and staff supporting activities; Major Commands and their subordinate commands, 

I installations, activities, and deployable units down to division and separate brigade level. 


I 
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The Information Architecture is a blueprint for developing plans and actions in 
the planning, control, and management of information. It consists of an information 
model and a functional, data, and geographical/technical architecture. 

The information model documents Army activities and information used or created 
by Army activities in support of Army missions and goals. The information model 
represents an organization’s processes, information classes (ICs)”, organizational units, 
and their relationships. 

The functional architecture is a decomposition of the process groups listed on the 
information model. It is used as a framework for current applications management and 
future application development. The data architecture represents an analysis of the 
information model and is used as a framework for organizing information. The 
geographic/technical architecture is the framework for managing the geographic, 
communications, and technology implications of data and applications distribution. 

The information systems architecture (ISA) is the physical implementation of the 
logical representation provided by the information architecture. This architecture 
provides technical guidance for modernizing IMA information syslem.s. The ISA 
incorporates emerging standards, technologies, and mission changes to overcome Army 
information systems baseline configuration shortfalls and to meet the IMA goal. The 
control architecture ensures the physical architecture (ISA) implements the logical 
architecture (i.e., the information architecture). 


C. DO A Data Management 

In 1983, the Vice Chief of Staff announced the need for a corporate data base, 
highlighting the adverse effect that conflicting and inconsistent data was having on Army¬ 
wide decisions. The corporate database project, although never completed, brought to 
the forefront the need for a data management program that would support the Army IRM 

”The Army defines an information class as a category of logically related information that 
supports the things of lasting interest the organization wishes to keep data about. 
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program through the use of common data structures throughout the Army. In September 
1989 the Anny established the Army Data Management and Standards Program (AR 25 - 
9). This program implements data management for the IMA and the AIRMP. 
According to AR 25-9, the data management program will; 

• Ensure that the mission-essential data requirements of commanders and decision 
makers are identified, documented, and supported. 

• Exploit data as a shared resource to improve mission effectiveness and efficiency 
over the spectrum of conflict. 

• Set the standards for accuracy, security, and synchronization of data in Army 
Data bases and information systems. 

• Develop an understanding of data storage and access requirements that will be 
useful in developing standard Army information systems and data bases. 

The Army believes that by identifying mission-essential data, exploiting data as 
a shared resource, setting standards for data and Army information systems they will be 
able to; 

• Manage data effectively and efficiently throughout their life cycle. 

• Establish and maintain data architectures that support the Army’s information 
requirements. 

• Promote the development of applications independent of the data. 

• Maintain and control data in databases so they are accessible by many 
applications. 

• Promote the sharing of data by combining similar user data requirements and 
establishing interoperability requirements. 

• Work to promote the smooth movement of shared data among the three IMA 
environments: strategic, theater/tactical, and sustaining base. 

The Army data management program consists of six activities. These activities 
and their objectives are listed in Table 6. The Army has developed specific guidance for 
their strategic data plamiing and data elements standards. This guidance is provided in 
Army Data Management and Standards Program Administrative Procedures Guide (DA 
Pam 25-9-1). 'fhe strategic data planning and data elements standards activities, as 
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Activity 


Strategic Data Planning 

Develop and maintain long-range planning 
documents which reflect data-related 
information requirements. 

Data Element Standards 

Develop policies and procedures for 
creating, standardizing, storing, and 
managing sharable Amy data and data 
resources. 

Information Management Control 

Coordinate data requirements between the 
data management program and the 
Management Infomation Control System. 

Data Security 

Develop policies and procedures required 
to protect data and information. Data 
security includes the physical protection 
of data, control of user access and the 
collection and dissemination of 
information. 

Data Synchronization 

Develop policies and procedures that 
govern the consistency, accuracy, 
reliability, and timeliness of data used and 
generated by the Army. It also addresses 
the planning, storage, scheduling, and 
maintenance of data and the exchange of 
data among authorized users and systems. 

Database Development 
and Maintenance 

Develop policies and standards that guide 
design, development, documentation, and 
integration of databases. It includes 
standard procedures and methods for 
developing consistent database 
maintenance practices. 


Table 6. Army Data Management Activities 


outlined in DA Pam 25-9-1, will be discussed in greater detail in the following sections. 
The Army is still developing guidance regarding the last four activities. 









D. Strategic Data Planning 


Strategic data planning is the process that the Army has selected for their data 
management strategy. This planning process produces a plan which addresses: 

• How Army organizations will develop and maintain a set of models and 
architectures which represent the organization and its information requirements. 

• How the data-related information requirements of the oiganization will be met as 
it moves from its baseline configuration to its objective. 

The plan also includes an initial set of functional and data architectures and models which 
represent the organization. 

Strategic data planning functions are conducted by major Army organizations and 
occur during the four phases of the Army’s information engineering process. These 
phases include; 

• Information Requirements Study (IRS) 

® Information Requirements Study Implementation (IRSI) 

• Functional Area Analysis (FAA) 

• Information System development 

The IRS is a formal study conducted to determine organization-wide information 
requirements. During the IRS, high-level functional and data modeling are conducted 
and the initial organizational information model is developed. Further analysis of the 
organization’s information model is conducted in the IRSI. In the IRSI phase, the 
functional and data models developed earlier are expanded and used to create a more 
detailed information model as well as the organization’s initial functional and data 
architectures. 

During FAA, a particular functional are.' is studied and modeled in significant 
depth. Detailed data and functional models are constructed. Data models developed 
during the FAA are integrated into the enterprise-wide data model. When the 
organization determines that there is a requirement for a new information system, models 
produced by the strategic data planning process are expanded to highly detai'al data and 
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activity mcxJels for the system under development. Data requirements for the new system 
are compared with the enterprise and functional data models. Any data element that does 
not exist as a standard are developed using the Army’s standardization procedures and 
added to the organization’s information model. 

I 

I 

I 1. Modeling Using IDEF 

I 

The focus of the Army’s strategic data planning is on modeling; specifically the 
development of a set of models representing the organization and its data. There are two 

types of models developed during the Army’s strategic data planning process: functional 

-* I 

I models and data models. 

I The Army uses functional models, also know as "process" or "activity" models, 

I 

j to show a hierarchical breakdown of the activities undertaken by an organization. Army 

' functional models identify inputs, outputs, controls, and mechanisms involved with each 

of the activities in the organization. 

Data models are used by the Army to depict the entities of principal concern to 
j the organization and the way that the entities relate to each other. The data model is 

I later used to help determine and define the data the organization must track and provides 

the framework which enables the data to be standardized. 

1 -' 

I The methodology the Army has selected for modeling is IDEF^^. IDEF is a 

I ) methodology which maps out the primary activities of strategic data planning. This 

; methodology consists of two parts: 

I j • IDEFO: used for development of functional models. 

\ 

L • IDEFIX: used for development of data models. 


^•’IDEF stands for ICAM (Integrated Computer Aided Manufacmring) Definition Language. 
It is beyond the scope of this paper to provide detailed documentation of the IDEF methodology. 
For information concerning the IDEF methodology see "Corporate Information Management 
Process Improvement Methodology for DoD Functional Managers". 
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2. Army Data Model 
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The Anny Data Model is an integrated consolidation of all the functional area data 
models developed during the functional area analysis phase in information engineering. 
The Army data model seives as the basis for data definition, integration and sharing 
across the Army and includes the business mles concerning Army data. Any system 
which creates or uses shared data will base this data on the Army data model. The Army 
data model is intended to be the Army’s conceptual schema for corporate data. The 
conceptual schema represents a view of the data which is independent of both users (or 
applications) and systems (software and/or hardware). 


E. Data Element Standards 

One of the principal uses of data models is to serve as the basis for creating 
standardized data elements. Standard data elements are attributes of entities that have 
been defined and documented during the modeling process. The goals of Army data 
standardization are; 

• To provide an Army-wide data framework for information system development 

• Facilitate the sharing of data 

« Support the integration of systems 

The Army uses a four step procedure to standardize data elements, as discussed 

below. 


1. Data Identification 

The need for a data element may be discoveied during the modeling process of 
one of the information engineering phases or during an information system development 
effort. Once the requirement for a data element is identified, it is placed into the data 
model under the logical entity in the data model the data element describes. If the 
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correct entity does not exist in the model, the developer proposes an addition, expansion 
or correction to the model to include the correct entity. Information Class Proponents 
must approve this change and the change must be fully iategrated into the Army data 
model, 

A search is conducted of existing data standards as well as proposed and candidate 
standards to determine if an existing standard element satisfies the data requirement. If 
no suitable element is found, the developer moves on to the next step. 


2. Research of the Element 

The purpose of the research is to separate the identity of the data (what it is) from 
its applications (how it is used). Research is used to compile adequate information to 
develop a well-fotmed domain definition and, if required, a comprehensive list of data 
values the element may assume. Once a data element’s domain has been identified, the 
appropriate reference element” is detennincd. If no suitable reference element exists, 
the developer requests a change to an existing reference element or develops and 
proposes a new one. 


3. Dennition/Constructiou of the Element 

After the basic research is conducted, the element is documented and submitted 
for approval. This involves the documentation of the element’s attributes, which include 
its domain, name, qualities, a rigorous definition, and administrative information. 

The data element name is developed by applying the Army’s naming convention. 
The data element name format, depicted in Figure 10, is composed of two parts: Prime 
Term and Reference Element Name. The prime term describes what the data element 


reference element, al.so called a "generic element", identifies the structure and physical 
characteristics of the data values in a domain. Examples of reference elements are: Name, Code, 
and Date. 


46 






Figure 0. Amy Data Element Naming Structure 

represents. It is built around a prime word which is the name of an entity in the Army 
Data Model. In the example, the data element name IruUvidml Marital Status Code is 
buUd around the entity Individual and describes a particular characteristic of that entit) 

The element name must have one word designated as the prime word. The prime 
word may be in any one of the six modifier positions within tlie prime term. The data 
element name can have up to five optional modifiers added to the prime woid to fiiUy 
describe the characteristic the data element r^resents. 

The second part of the data element name is the associated reference element 
name. It identifies the domain values or type of data that can be assigned to the data 
element. In the example, the reference element name is Code. Values assigned to this 
data element may be S (single), M (manied), D (divorced), etc. The data element name 
must have a prime term followed by a reference element name. 

The data element name is the designation given to a data element. This is a 
descriptive name for reference ai.d is not designed to be incorporated into software 
applications. To use the data element in a software application, the data element is 
assigned mnemonic abbreviations. These are unique short forms of the data element 
name. There are three types of mnemonic abbreviations — short mnemonic abbreviation 
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(8 or fewv r characters), regular mnemonic abbreviation (18 or fewer characters), and 
long mnemonic abbreviation (32 or fewer characters). 


4. Validation of the Element 

The developer must ensure that the element can be used universally across all 
echelons of the Army and DoD. Standardization efforts require coordination with subject 
matter experts and functional proponents to determine if data requirements have been 
adequately met. If other data standards are impacted, organizations must woilc jointly 
to biing affected data into compliance with data standards. Organizational data 
administrators will ensure that standard elements are being used. 

F. DOA Data Management Tools 

The Army’s data management program could not have been implemented without 
the use of a set of tools that would allow them to automate their modeling and 
standardization methodologies. To assist in the standardization, documentation, and 
storage of data, the Array developed the Army Data Dictionary/Automated Dictionary 
Support System (ADD/ADSS). To support their modeling efforts, the Army is in the 
process of developing the Army Data j^incyclopedia. In the interim, the Army has been 
able to utilize an encyclopedia that was developed by the Army Corps of Engineers. 
The capabilities of the ADD/ADSS and the future ADE are discussed below. 


1. Army Data Dictionary/Automated Dictionary Support System 

The ADD/ADSS provides a mechanism to capture and merge the information the 
Army needs to manage its data resources effectively. The ADD/ADSS is a rqxjsitory 
used to approve and record standard elements to be used in Array information systems. 
Users and systems developers can access the dictionary to find existing proposed, 
candidate or standard e- iments. New data elements can be submitted on-line or in batch 
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as candidate or proposed elements. Information Class Proponents and the Army Data 
Administrator can perform on-line functional and technical approval, respectively. Users 
of the dictionary can also obtain reports and perform queries. 


2. Army Data Encyclopedia 

The ADD is actually the preliminary form of a much more sophisticated tool 
called the Army Data Encyclopedia (ADE), which is currently planned for development 
by the Information System Engineering Command. The ADE design will be consistent 
with the IRDS standard and will support the Army objective to Held and operate 
interoperable and integrated systems. 

The ADE will support and enhance the effective and efficient management of the 
creation, documentation, use, modification, mauitenance, standardization, and disposition 
of shared data throughout the Army. Once completed, the ADE will provide an 
integrated repository of metadata to include architectures, data models, internal models, 
external views, data elements, directory information activity models, organizational 
models, and other metadata required. 


G, Current DOA Data Management Implementation Status 


The Army began implementing their data management program in the Spring of 
1990. Since that time, 19 ftinctional areas that represent the way the Anny does business 


avw' iA^ii luwiiiuiM. luu^uuiiai cucas oTo uaicAi ni iaujc /. xiic /viiiiy 


to identify additional functional areas as they derive more detailed models. These 
functional areas will likely be identified by components that receive guidance from the 
Joint arena (i.e., Special Forces) and therefore were missed during high-level (strategic) 
modeling. 


Modeling teams consist of no more than ten people and include a mix of 
functional experts who know the organization’s business and technical experts who 
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• 

Inspector General 

• Deputy Chief of Staff for 

Personnel 

• 

Judge Advocate General 

• Director of Management 

• 

Financial Management 

• Director Information Systems for 

Command Control and 
Communication 

# 

Rese.arch and Development 

• Office of the Director Under 


Acquisition 

Secretary of the Army 

• 

Chaplains 

• Program Analysis and Evaluation 

• 

Corps of Engineers 

• Secretary' of Army Management 

and System support 

• 

Deputy Chief of Staff 
for Intelligence 

• Surgeon General 

• 

Deputy Chief of Staff 

• Army Audit Agency 


for Logistics 


m 

Deputy Chief of Staff 
for Operations and Plans 

• Chief of Legislative Liaison 

• Chief of Public Affairs 


Table 7. Anny Functional Areas 


understand the modeling methodology and are familiar with modeling techniques. 
Personnel selected to participate in modeling a particular functional area undergo a one 
to two week training course. This course presents an overview of the National Institute 
of Standards and Technology (NIST) standards for data modeling, introduces the IDEF 
methodology, and teaches participants how to build Hmctional and data models. 

The Army schedules a five week block of time for a functional area modeling 
session. With the exception of Logistics, tlus tin e frame has provided Army 
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organizations with enough time to complete strategic modeling and, in some cases, to 
bring the model dov/n to raid-level management (tactical) or operational activities. The 
Logistics functional anKi is so large, that their first strategic modeling session resulted 
in a model that was recognized as too high level to be useful. logistics was 
subsequently scheduled for an additional 10 week modeling session in order to capture 
all strategic data and begin mid level modeling. 

Another problem the Army had with some of their initial modeling sessions was 
that functional area managers did not carefully select appropriate personnel to participate 
in the modeling session. The result was modeling teams made up of personnel who were 
experts in only a few activities within their functional area, therefore some activities 
within the functional area were missed. This problem arose because functional managers 
did not understand the modeling methodology and/or had low expectations with respect 
to the benefits of modeling. 

The Army has corrected the modeling team staffing problem by selecting 
pereonnel who have a broad knowledge of the functional area and supplementing the team 
with subject area experts (personnel who are experts in one particular activity within the 
functional area) when required. Most functional managers now have a better 
understanding of the modeling process and recognize that modeling will assist in 
identifying areas in which budget cuts can be made. 

Cuirently, 16 of the 19 functional areas have completed at least strategic 
modeling. Tlie remaining functional areas (Army Audit Agency, Chief of Legislative 
Liaison, and Chief of Public Affairs) are awaiting funding and are expected to complete 
strategic modeling by November 1992. Some functional areas have continued with the 
modeling process and are at various stages of mid-level management or operational 
modeling. The degree to which functional areas model business activities and data has 
been driven by: 

• New information system development requiring more in-depth modeling to 
identify data needs. For example, certain activities within Operations and 
Personnel have been brought down to mid-level or operational activity functional 
and data models to support the Reserve Component Automation System (RCAS) 
development. 
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• The ability of the modeling team to complete the model because their functional 
area is small (Chaplains). 

• Functional experts desire to complete modeling because they have mastered the 
modeling techniques. This is happening with the Logistics functional area. 

• Functional proponents belief that functional and data modeling is extremely 
valuable in identifying areas in which they can apply re-engineering techniques 
in the wake of budget decreases. 

The Army has integrated 14 of the 16 functional area data models into the Army 
Data Model. Because personnel responsible for integrating functional data models into 
the Army Data Model are also assisting functional areas in their modeling effort, 
integration lags functional modeling by about a month. 


The modeling effort has thus far identified over 650 entities, of which 340 are 
approved. There are currently more than 2450 data elements in the ADD, approximately 
30% are standardized whereas the other 70% are still undergoing evaluation. The Army 
estimates that on average, every data element identified and standardized could replace 
eight synonym data elements that exist in current information systems. 


The Army’s goal is to standardize an entity within 30 days and a data element 
within two weeks (including functional review and approval by the information class 
proponent (ICP) and technical review and approval by the Army data administrator) . 
Initially, data entities required five to six months and elements up to four months to 
standardize. Now that ICP’s and the Army data administrator staff have a better 
understanding of their roles, know how to use the ADD/ADSS, and have mastered the 


Army’s naming convention, the Army has reduced the entity standardization to four 
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why the Army has not yet met their standardization time goals: 

• Strategic modeling identifies a large portion of the entitie. that are of concern to 
the organization. Therefore, the ICP’s and data administrator staff have been 
inundated with a large number of entities and key elements in a short period of 
time. 
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Data element identification and naming hinges on entity approval, therefore the 
Army is taking time to ensure that data entities are well formulated. 







• Army data administrator staff personnel are currently spread thin trying to support 
the modeling development and integration effort, conduct Army to DoD data 
model comparisons, and perform technical review and approval of data entities 
and elements. 

The Army expects to complete at least mid-level modeling by September 1994, 
This target date depends on the availability of personnel and budgetary resources. 
Operational level modeling will be prioritized for functional area activities as required 
by new information system development or as requested by functional area managers if 
budgetary resources are available. The Army Information Architecture is also evolving. 
The Information Architecture’s information model and functional and data architectures 
reflect most of the strategic modeling effort that has been completed thus far. The 
Geographic/Technical Architecture is on hold until the Army can identify a tool that will 
assist in its development. 

It is important to realize that completion of the modeling process and the 
integration of those models into the Army Data Model and Information Architecture 
provides the Army with a baseline representation of their functional processes and 
activities and the data that is -"reated and used by functional areas. As re-engineering 
techniques are applied and new information systems are developed, the functional 
models, and to a lesser extent the data models, will have to be updated to reflect those 
changes. Thus, the Army’s initial modeling effort is only the beginning of a continual 
process. Long-tenn benefits of this process can be realized only if the models and 
architectures are kept up-to-date. 
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V. Lessons Learned 


A. Commitment by Management is Essential 

Management commitment is essential when organizations undergo cliange. This 
commitment must be shared by upper management as well as functional managers. 
Upper management commitment ensures that resources will be available to institute the 
change. Functional management commitment ensures the change is implemented 
successfully. 

Gaining commitment from maiiagement has not been easy for the Army. A 1990 
Government Accounting Office (GAO) report stated that the Army’s efforts to improve 
management and acquisition of its information resources had not been fully successful. 
According to the GAO, the Army did not adequately pursue the development of an 
information architecture and cited a lack of local commanders’ commitment as one of the 
problems. 

Although there still remain pockets of contention, the majority of Army 
management has found that their ERM and data management program efforts will allow 
them to continue their mission in an environment where downsizing and shrinking 
budgets are a reality. 


B. Data Manager Must be in a Position of Authority 

In order for a data m'>nagement program to be successful, the data manager must 
be in a position of authority to set policy and ensure the appropriate plans and controls 


’"GOA/IMTEC 90-58 
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are implemented. All too often the data manager is several levels down in the 
organization and has little input in strategic decision making. The Army has ensured tliat 
data management issues are addressed by giving DISC4 overall responsibility for the 
Army’s IRM and data management programs. 

C. Effective Communication is Key 

When the policy and implementation functions of data management are separated 
(both geograpliically and functionally), there must be a close working relationship 
between those who set policy and those who implement it. As with any military 
organization, Army policy is set by upper management and implemented by functional 
managers much lower in the chain of command. The Army has found that without 
effective communication, a well intentioned policy will be difficult to implement in the 
manner in which it was intended. A majority of Army managers have stated that they 
wish they understood the value of the Army information model five years ago. As one 
Army officer put it "We had a vision, we just did not do a good job of articulating it." 


D. Technical Tools are Invaluable 

The data manager, data administrators, and database administrators must have the 
technical tools available to implement the data management policy. Tools such as the 
data dictionary, data encyclopedia, and I-CASE environments provide the means to 
automate data management methodologies as well as assist in the development and 
maintenance of strategic infoimation sysienis. 

The Army saw the need for such tools long before they began implementing their 
data management program. The Army Data Dictionary/Automated Dictionary Support 
System has been an invaluable tool for the Army not only for storing standard entities 
and element j and their attributes, but also for automating the approval process. Although 
the Army Data Encyclopedia is not complete, the Army has been able to use the Anny 


56 








Coqjs of Engineers encyclopedia as a mechanism to define and store their process and 
data models under IDEE modeling techniques. The ADD/ADSS and the Corps of 
Engineers encyclopedia are stand-alone tools. Currently the Army does not have the 
capability to link data entities and elements in the dictionary with the models contained 
in the encycloi)edia. The ADE planned should provide this integration in the future. 


£. Model the Data before Standardizing 

In order to understand what the business is, what it does, and what data it uses, 
the organization needs to perform modeling. By modeling, the organization can 
determine what data are essential to the organization and who uses it. Data 
standardization and naming conventions use the information obtained from modeling to 
properly define elements, name them, identify their attributes, and assign I'fecycle 
responsibilities. 

Initially, the Army Data Management and Standards Program stated that data 
element standardization begins when data elements required upport applications are 
identified during development of an information system. The Army began standardizing 
personnel elements needed for the Standardized Installation/Division Personnel System 
(SIDPERS) using AR 25-9 procedure.s. 

The Army soon realized that standardizing entities and elements for SIDPERS 
would not help in identifying what other functional areas required access to portions of 
the personnel data or if that data value should be captured by another fn actional area and 
shared with personnel. This problem occurred because the data management program 
was data element specific, in that it providi n«:»Hcies for naming data elements, but did 
not address procedures for identifying strategic data. The Army data management 
program has been revised to include data modeling as a basis for the identification of 
Army data. The Army Data Model serves as a conceptual framework for Army data. 
This model is than expanded, as needed, when new systems com. on-line. 
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F. Eud-Users Play a Critical Role 


End-users must be involved with data management activities. They are the 
resident experts on how the business operates and what data is required to perform the 
job. They can provide valuable insight for the data modeling process and directly affect 
the success of any data management program. The Army’s modeling teams directly 
involve the end-user. However, the Army found that selecting the right end-users to 
participate is just as imiwrtant. 

Initially, functional area managers did not carefully select personnel to participate 
in the modeling process. This practice resulted in incomplete models because modeling 
team members could not lend expertise in all activities within the functional area. 
Selecting the wrong personnel was caused by a lack of understanding by management 
regarding the modeling process, as well as low expectations by management with respect 
to overall benefits. 

Fortunately, the Army identified this weakness after initial modeling activities. 
The Army now' stresses the use of functional experts, who possess a broad understanding 
of the organization and its mission, to provide the overall functional knowledge during 
modeling sessions. Subject matter experts are called in as necessary to support the 
modeling effort and to review modeling products. By ensuring that end-users, and in 
particular, experts, play an active role in the data management effort, the Army has 
paved the way for a successful program. 


G. Data Management Programs Take Time and Resources 

An organization can not be expected to revolutionize the way they handle their 
data resources overnight. Many organizations hesitate to invest resources for a program 
which does not reveal immediate benefits. A sound data management program provides 
long term benefits, but requires an up-front contribution of personnel, time, and 
budgetary resources. 


58 


RWTa«iotigr gca8azia «aiifc.i I II 








The Army Data Management Program began in 1983 when the Army realized that 
conflicting and inconsistent data was having an adverse effect on Army decision making. 
It has taken nine years for the Army to develop policies, procedures, and tools that will 
allow them to manage their data resources effectively. 

The Army has not completed initial implementation of their data management 
progiam (i.e., modeling the 19 functional areas). The reasons for this are numerous; 

• Budgetary constraints 

• Personnel constraints 

• Lack of initial commitment to the program 

• Lack of initial expertise in data management methodologies and modeling 

• Size and scope of the DOA 

However, the Army has made great strides and have already received some benefits from 
their data management program by identifying redundant activities within functional areas 
which may be eliminated. 


H. Data Management and IRM is a Continual Process 

Developing an initial set of models and architectures and standardizing the data 
identified during modeling is only the beginning of the data management and IRM 
process. Organizations are not static; they change as the enviromnent in which they 
operate change. As organizations take advantage of the information obtained from the 
modeling effort and employ re-engineering techniques, or develop new information 
systems and apply new technology based on the plans produced from the IS architecture, 
the functional and data models and IS architecture must be updated to continue to benefit 
the organization. 

The Anny is just beginning this process. Long-term benefits are still on the 
horizon, but are achievable if the Army continues to apply and enforce their data 
management and IRM strategies. For other DoD organizations that have not yet begun 
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developing or implementing a comprehensive data management and ERM program, they 
can shorten the pi^ocess by learning from the Army’s mistakes and repeating their 
successes. 
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Glossary of Terms 


t 

i. 


ADD/ADSS - Army Data Dictionary/Automated Dictionary Support System. 

ADE - Army Data Encyclopedia. 

APPLICATIONS ARCHITECTURE > A framework that represents computer programs that 
perform tasks associated lo a particular business function. 

ARCHITECTURE - A framework for specifying how components of a system fit together, 
CASE - Computer-Aided Software Engineering. 

CIM - Corporate Information Management. 

COMMUNICATIONS ARCHITECTURE - A framework for developing a communication 
network to link hardware, software and information. 

DATA • Meaningful facts about persons, places, things, concepts, events, and activities in a 
defined format and structure from which information may be derived. 

DATABASE ADMINISTRATOR - The organization’s technical expert on database related 
activities, who is also responsible for the operation of the datab.ise.s. 

DATA ELEMENT - A characteristic or attribute of an entity. 'Hie lowest level of addressable 
data. 

DBMS (DATABASE MANAGEMENT SYSTEM) - A set of programs thi'.t are used to define, 
process, and administer the data base and its applications. 

DATA ADMINISTRATOR - A person who has overall responsibility for the organkation’s data 
resources. 

DATA ARCHITECTURE - A framework tor organizing ai.' defining the interrelationships of 
data in support of an organization’s information architecture. The data that will be used to bind 
all the other architectures together. 

DATA DICTIONARY - A centr alized repository of information about data. 
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DATA DICTIONARY SUBSYSTEM - Facilitates storage of the organization’s metadata and 
has the capability to relate that information in such a way that the organized metadata serves a 
useful purpose. 

DATA MANAGEMENT - The process of locating, organizing, cataloging, storing, retrieving, 
and maintaining data which is fundamental to the organization. 

DATA MODEL - Describes the entities, their attributes and interrelations that are necessary to 
support the business processes. 

DATA STANDARDIZATION - Provides a common structure which involves naming the entity 
using the organization’s naming convention, providing a precise definition, identifying its 
characteristics (attributes), and developing access keys. 

DISC4 - Director Information Systems for Command, Control, Communications and Computers. 
DOA - Department of the Army. 

DoD - Department of Defense. 

DOMAIN - Specifies format, length, and special restrictions on the value of each domain. 

ENCYCLOPEDIA - An extension of the data dictionary used to develop and store data models 
and architectures and documents their relationship to the data stored in the data dictionary. 

END-USER - A collective term used for anyone who uses data and applications to provide 
information. 

ENTITY - Any person, place or thing that has meaning to a user. 

ENTITY-RF,LATIONSHIP DIAGRAM - A diagram which depicts the relationships between 
entities (ie. not related, one-to-raany, one-to-one). 

FILE PROCESSING SYSTEM - A computer system which has corporate information embedded 
within the application program’s source code. 

FUNCTIONAL AREA - Any area within an organization that has a definable set of tasks. 

FUNCTIONAL MODEL - Depicts the activities or processes an organization perfonm to 
accomplish its mission. 

HARDWARE/SOFTWARE ARCHITECTURE - A framework to provide the processing power 
needed to run applications that will generate and distribute information. 

INFORMATION ENGINEERING - A process which analyzes the strategic information needs 
of the organization. 

INFORMATION SYSTEM - Activities and resources concerned with the creation, gathering, 
manipulation, classification, storage and transmission of elements of information. 
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INFORMATION SYSTEMS ARCHITECTURE - A framework within which fiiture IS 
development, procurement, and implementation activities can occur. 

INFORMATION RESOURCE MANAGEMENT (IRM) - The process of directing or 
controlling the use of an information .system comprised of any combination of hardware, 
software, procedures, documents or people that transforms data into a meaningful and u.seful form 
for satisfying organizational goals and objectives. 

METADATA - Data about the structure of data stored in the data dictionary. It includes the data 
name, format, domain as well as other characteristics. 

SCHEMA - The structure of the database or how data is physically stored. 

STOVEPIPE SYSTEM - A system developed to meet one functional area without taking into 
account other functional areas which potentially use the same information. 

STRATEGIC DATA PLANNING - A top-down strategy for identifying and understanding data 
in the context of the overall business functions. 

STRATEGIC ENVIRONMENT - Within information mission area (IMA), the environment 
which links the Theater/Tactical and Sustaining Base Environments. 

SUBSCHEMA - A family of applications to process portions of the data or how tlie user views 
the data. 

SUSTAINING BASE ENVIRONMENT - The area and information resources outside of the 
area of operations that have the responsibility to raise, organize, train, equip, and eventually, 
deploy and sustain Army forces in the accomplishment of their mission in operational theaters. 

THEATER/TACTIC AX- ENVIRONMENT - Army area of operations. 

USAISC - United States Army Information Systems Command. 
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